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MIME Encapsulation of Macintosh files - MacMIME 


Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


This memo describes the format to use when sending Apple Macintosh 
files via MIME [BORE93]. The format is compatible with existing 
mechanisms for distributing Macintosh files, while allowing non- 
Macintosh systems access to data in standardized formats. 


2. Introduction 
Files on the Macintosh consists of two parts, called forks: 


Data fork: The actual data included in the file. The Data 
fork is typically the only meaningful part of a 
Macintosh file on a non-Macintosh computer system. 
For example, if a Macintosh user wants to send a 
file of data to a user on an IBM-PC, she would only 
send the Data fork. 


Resource fork: Contains a collection of arbitrary attribute/value 
pairs, including program segments, icon bitmaps, 
and parametric values. 


Additional information regarding Macintosh files is stored by the 
Finder in a hidden file, called the "Desktop Database". 


Because of the complications in storing different parts of a 
Macintosh file in a non-Macintosh filesystem that only handles 
consecutive data in one part, it is common to convert the Macintosh 
file into some other format before transferring it over the network. 
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The two styles of use are [APPL90]: 


AppleSingle: Apple’s standard format for encoding Macintosh files 
as one byte stream. 
AppleDouble: Similar to AppleSingle except that the Data fork is 


separated from the Macintosh-specific parts by the 
AppleDouble encoding. 


AppleDouble is the preferred format for a Macintosh file that is to 
be included in an Internet mail message, because it provides 
recipients with Macintosh computers the entire document, including 
Icons and other Macintosh specific information, while other users 
easily can extract the Data fork (the actual data) as it is separated 
from the AppleDouble encoding. 


2. MIME format for Apple/Macintosh-specific file information 


2a. APPLICATION/APPLEFILE 


MIME type-name: APPLICATION 

MIME subtype name: APPLEFILE 

Required parameters: none 

Optional parameters: NAME, which must be a "value" as 
defined in RFC-1521 [BORE93]. 

Encoding considerations: The presence of binary data will 


typically require use of 
Content-Transfer-Encoding: BASE64 


Security considerations: See separate section in the document 
Published specification: Apple-single & Apple-double [APPL90] 
Rationale: Permits MIME-based transmission of 


data with Apple/Macintosh specific 
information, while allowing general 
access to non-specific user data. 


2b. MULTIPART/APPLEDOUBLE 


MIME type-name: MULTIPART 

MIME subtype name: APPLEDOUBLE 

Required parameters: none 

Optional parameters: NAME, which must be a "value" as 
defined in RFC-1521 [BORE93]. 

Encoding considerations: none 

Security considerations: See separate section in the document 

Published specification: Apple-single & Apple-double [APPL90] 

Rationale: Permits MIME-based transmission of 


data with Apple/Macintosh specific 
information, while allowing general 
access to non-specific user data. 
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2c. Detail specific to MIME-based usage 


Macintosh documents do not always need to be sent in a special 
format. Those documents with well-known MIME types and 
non-existent or trivial resource forks can be sent as regular 
MIME body parts, without use of AppleSingle or AppleDouble. 


Documents which lack a data fork must be sent as AppleSingle. 


Unless there are strong reasons not to, all other documents 
should normally be sent as AppleDouble. This includes documents 
with non-trivial resource forks, and documents without 
corresponding well-known MIME types. 


It may be valuable in some cases to allow the user to choose one 
format over another, either because he disagrees with the 
implementor’s definition of "trivial" resource forks, or for 
reasons of his own. 


3. AppleSingle 


An AppleSingle, version 2 file, is sent as one consecutive stream of 
bytes. The format is described in [APPL90] with a brief summary in 
Appendix A. The one and only part of the file is sent in an 
application/applefile message. 


The first four bytes of an AppleSingle header are, in hexadecimal: 
00, 05, 16, 00. 


The AppleSingle file is binary data. Hence, it may be necessary to 
perform a Content-Transfer-Encoding for transmission, depending on 

the underlying email transport environment. The safest encoding is 
Base64, since it permits transfer over the most restricted channels. 


Even though an AppleSingle file includes the original Macintosh 
filename, it is recommended that a name parameter be included on the 

Content-Type header to give the recipient a hint as to what file is 

attached. The value of the name parameter must be a "value" as 

defined by RFC-1521 [BORE93]. Note that this restricts the value to 
seven-bit US-ASCII characters. 


3a. AppleSingle example 
Content-Type: application/applefile; name="Computers-1/2-93" 
[The AppleSingle file goes here] 


4. AppleDouble 
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An AppleDouble, version 2, file is divided in two parts: 


Header: including the Macintosh resource fork and desktop 
information and 
Data fork: containing the Macintosh data fork. 


The AppleDouble format is described in [APPL90] with a brief summary 
in Appendix B. 


The AppleDouble file itself is sent as a multipart/appledouble MIME 
body-part, which may have only two sub-parts. The header is sent as 
application/applefile and the data fork as whatever best describes 
it. For example, is the data for is actually a GIF image, it should 
be sent as image/gif. If no appropriate Content-Type has been 
registered for the data type, it should be sent as an 
application/octet-stream. 


The first four bytes of an AppleDouble header are, in hexadecimal: 
00, 05, 16, O7. 


The AppleDouble header is binary data. Hence, it may be necessary to 
perform a Content-Transfer-Encoding for transmission, depending on 
the underlying email transport environment. The safest encoding is 
Base64, since it permits transfer over the most restrictive channels. 


Even though an AppleDouble file includes the original Macintosh 
filename, it is recommended that a name parameter be included on the 
Content-Type header of both the header and data parts of the 
AppleDouble file to give the recipient a hint as to what file is 
attached. The value of the name parameter must be a "value" as 
defined by RFC-1521 [BORE93]. Note that this restricts the value to 
seven-bit US-ASCII characters. 


4a. AppleDouble example 
Content-Type: multipart/appledouble; boundary=mac-part 


--mac—part 
Content-Type: application/applefile; name="My-new-car" 


[The AppleDouble header goes here] 


--mac—part 
Content-Type: image/gif; 


[The data fork goes here] 


==Mac-—part== 
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6. Security Considerations 


To the extent that application/applefile facilitates the transmission 
of operating-system sensitive data, it may open a door for easier 
relaxation of security rules than is intended either by the sender of 
the administrator of the sender’s system. 
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Appendix A. The AppleSingle format 


In the AppleSingle format, a file’s contents and attributes are 
stored in a single file in the foreign file system. For example, 
both forks of a Macintosh file, the Finder information, and an 
associated comment are arranged in a single file with a simple 
structure. 


An AppleSingle file consists of a header followed by one or more data 
entries. The header consists of several fixed fields and a list of 
entry descriptors, each pointing to a data entry. Each entry is 
optional and may or may not appear in the file. 


AppleSingle file header: 


Field Length 

Magic number 4 bytes 
Version number 4 bytes 
Filler 16 bytes 
Number of entries 2 bytes 


Entry descriptor for each entry: 


Entry ID 4 bytes 
Offset 4 bytes 
Length 4 bytes 


Byte ordering in the file fields follows MC68000 conventions, most 
significant byte first. The fields in the header file follow the 
conventions described in the following sections. 


Magic number 
This field, modelled after the UNIX magic number feature, 
specifies the file’s format. Apple has defined the magic number 
for the AppleSingle format as $00051600 or 0x00051600. 


Version number 
This field denotes the version of AppleSingle format in the event 


the format evolves (more fields may be added to the header). The 
version described in this note is version $00020000 or 
0x00020000. 

Filler 


This field is all zeros ($00 or 0x00). 


Number of entries 
This field specifies how many different entries are included in 


Faltstrom, Crocker & Fair [Page 7] 


RFC 1740 MIME-based Mac files December 1994 


the file. It is an unsigned 16-bit number. If the number of 
entries is any number other than 0, then that number of entry 
descriptors immediately follows the number of entries field. 


Entry descriptors 
The entry descriptor is made up of the following three fields: 


Entry ID: an unsigned 32-bit number, defines what the entry is. 
Entry IDs range from 1 to SFFFFFFFF. Entry ID 0 is 
invalid. 

Offset: an unsigned 32-bit number, shows the offset from the 
beginning of the file to the beginning of the entry’s 
data. 

Length: an unsigned 32-bit number, shows the length of the 
data in bytes. The length can be 0. 


Predefined entry ID’s 


Apple has defined a set of entry IDs and their values as follows: 


Data Fork 1 Data fork 

Resource Fork 2 Resource fork 

Real Name 3 File’s name as created on home file 
system 

Comment 4 Standard Macintosh comment 

Icon, B&W 5 Standard Macintosh black and white icon 

Icon, Colour 6 Macintosh colour icon 

File Dates Info 8 File creation date, modification date, 


and so on 


Finder Info 9 Standard Macintosh Finder information 

Macintosh File Info 10 Macintosh file information, attributes 
and so on 

ProDOS File Info 11 ProDOS file information, attributes and 
so on 

MS-DOS File Info 12 MS-DOS file information, attributes and 
so on 

Short Name 13 AFP short name 

AFP File Info 14 AFP file, information, attributes and so 
on 

Directory ID 15 AFP directory ID 


Apple reserves the range of entry IDs from 1 to $7FFFFFFF. The 
rest of the range is available for applications to define their 
own entries. Apple does not arbitrate the use of the rest of the 
range. 


Appendix B. The AppleDouble format 
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The AppleDouble format uses two files to store data, resources and 
attributes. The AppleDouble Data file contains the data fork and the 
AppleDouble Header file contains the resource fork. 


The AppleDouble Data file contains the standard Macintosh data fork 
with no additional header. The AppleDouble Header file has exactly 
the same format as the AppleSingle file, except that it does not 
contain a Data fork entry. The magic number in the AppleDouble 
Header file differs from the magic number in the AppleSingle Header 
file so that an application can tell whether it needs to look in 
another file for the data fork. The magic number for the AppleDouble 
format is $00051607 or 0x00051607. 


The entries in the AppleDouble Header file can appear in any order; 
however, since the resource fork is the entry that is most commonly 
extended (after the data fork), Apple recommends that the resource 
fork entry to be placed last in the file. The data fork is easily 
extended because it resides by itself in the AppleDouble Data file. 


Appendix C. applefile.h 


This is an example of a header file for the language C which can be 
used when parsing the data in either an AppleSingle file or 
AppleDouble header. 


The file is written by Lee Jones. Distribution is unlimited. 
/ 


applefile.h - Data structures used by AppleSingle/AppleDouble 
file format 


Written by Lee Jones, 22-Oct-1993 


For definitive information, see "AppleSingle/AppleDouble 
Formats for Foreign Files Developer’s Note"; Apple Computer 
Inc.; (c) 1990. 


Other details were added from: 
Inside Macintosh [old version], volumes II to VI, 
Apple include files supplied with Think C 5.0.1, 
Microsoft MS-DOS Programmer’s Reference, version 5, and 
Microsoft C 6.00a’s dos.h include file. 


I don’t have ProDOS or AFP Server documentation so related 
entries may be a bit skimpy. 


Edit history: 


+ + + + + + + F FF FF FF FF FF FF F FF F F F OF 


when who why 


Faltstrom, Crocker & Fair [Page 9] 


RFC 1740 MIME-based Mac files December 1994 


* 22-Oct-93 LMJ Pull together from Inside Macintosh, 

* Developer’s Note, etc 

* 26-Oct-93 LMJ Finish writing first version and list 

x references 

* 06-Feb-94 EEF Very minor cleanup 

*/ 

/* Following items define machine specific size (for porting). */ 
typedef char xchar8; /* 8-bit field */ 
typedef char schar8; /* signed 8-bit field */ 
typedef unsigned char uchar8; /* unsigned 8-bit field */ 
typedef short xintl16; /* 16-bit field */ 
typedef unsigned short uintl16; /* unsigned 16-bit field */ 
typedef long xint32; /* 32-bit field */ 
typedef long sint32; /* signed 32-bit field */ 
typedef unsigned long uint32; /* unsigned 32-bit field */ 


/* REMINDER: the Motorola 680x0 is a big-endian architecture! */ 
typedef uint32 OSType; /* 32 bit field */ 


/* In the QuickDraw coordinate plane, each coordinate is 
-32767..32767. Each point is at the intersection of a 
horizontal grid line and a vertical grid line. Horizontal 
coordinates increase from left to right. Vertical 
coordinates increase from top to bottom. This is the way 
both a TV screen and page of English text are scanned: 
from top left to bottom right. 

/ 


+ + + + F F F 


struct Point /* spot in QuickDraw 2-D grid */ 
{ 
xint16 v; /* vertical coordinate */ 
xint16 h; /* horizontal coordinate */ 
}; /* Point */ 


typedef struct Point Point; 


/* See older Inside Macintosh, Volume II page 84 or Volume IV 
* page 104. 
47 


struct FInfo /* Finder information */ 


{ 
OSType fdType; /* File type, 4 ASCII chars */ 
OSType fdCreator; /* File’s creator, 4 ASCII chars */ 
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/* Finder flag bits */ 


fdLocation; /* file’s location in folder */ 
xint16 fdFldr; /* file ’s folder (aka window) */ 
}; /* FInfo */ 


typedef struct FInfo FInfo; 


/* 
* Masks for finder flag bits 
* FInfo). 

*/ 

#define F_fOnDesk 0x0001 

#define F_maskColor O0x000E 

/* 0x0010 

#define F_fSwitchLaunch 0x0020 

#define F_fShared 0x0040 

#define F_fNoINITs 0x0080 

#define F_fBeenInited 0x0100 

/* 0x0200 

#define F_fCustomIcom 0x0400 

#define F_fStationary 0x0800 

#define F_fNameLocked 0x1000 

#define F_fHasBundle 0x2000 

#define F_fInvisible 0x4000 

#define F_fAlias 0x8000 


/* See older Inside Macintosh, 


*/ 


/* 
/* 
/* 
/* 
/* 
/* 
/* 


(field fdFlags in struct 


file is on desktop (HFS only) */ 
color coding (3 bits) */ 

reserved (System 7) */ 

reserved (System 7) */ 

appl available to multiple users */ 
file contains no INIT resources */ 
Finder has loaded bundle res. */ 


/* reserved (System 7) */ 


/* 
/* 
/* 
/* 
/* 
/* 


file contains custom icon */ 

file is a stationary pad */ 

file can’t be renamed by Finder */ 
file has a bundle */ 

file’s icon is invisible */ 

file is an alias file (System 7) */ 


Volume IV, page 105. 


struct FXInfo /* Extended finder information */ 


{ 


xint16 
xintl16 
schar8 
schar8 
xint16 
xint32 
}; /* FXInfo */ 


fdIconID; /* icon ID number */ 
fdUnused[3]; /* spare */ 

fdScript; /* scrip flag and code */ 
fdxFlags; /* reserved */ 

fdComment; /* comment ID number */ 
fdPutAway; /* home directory ID */ 


typedef struct FXInfo FXInfo; 


/* Pieces used by AppleSingle & AppleDouble (defined later). */ 


struct ASHeader /* header portion of AppleSingle */ 


{ 


Faltstrom, 


/* AppleSingle = 0x00051600; AppleDouble = 0x00051607 */ 
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uint32 magicNum; /* internal file type tag */ 

uint32 versionNum; /* format version: 2 = 0x00020000 */ 

uchar8 filler[16]; /* filler, currently all bits 0 */ 

uintl16 numEntries; /* number of entries which follow */ 
}; /* ASHeader */ 


typedef struct ASHeader ASHeader; 


struct ASEntry /* one AppleSingle entry descriptor */ 
{ 
uint32 entryID; /* entry type: see list, 0 invalid */ 
uint32 entryOffset; /* offset, in octets, from beginning */ 
/* of file to this entry’s data */ 
uint32 entryLength; /* length of data in octets */ 
}; /* ASEntry */ 


typedef struct ASEntry ASEntry; 


/* Apple reserves the range of entry IDs from 1 to Ox7FFFFFFF. 
* Entry ID 0 is invalid. The rest of the range is available 


* for applications to define their own entry types. "Apple does 
* not arbitrate the use of the rest of the range." 
*/ 


/* data fork */ 

/* resource fork */ 

/* File’s name on home file system */ 
/* standard Mac comment */ 

Mac black & white icon */ 

/* Mac color icon */ 

/* not used */ 

/* file dates; create, modify, etc */ 
/* Mac Finder info & extended info */ 


#define AS_DATA 
#define AS RESOURCE 
#define AS REALNAME 
#define AS_COMMENT 
#define AS_ICONBW 
#define AS_ICONCOLOR 
/* 
#define AS_FILEDATES 
#define AS_FINDERINFO 


OMDANHDUAWNE 
™~ 
+ 


#define AS MACINFO 10 /* Mac file info, attributes, etc */ 
#define AS PRODOSINFO 11 /* Pro-DOS file info, attrib., etc */ 
#define AS MSDOSINFO 12 /* MS-DOS file info, attributes, etc */ 
#define AS_AFPNAME 13 /* Short name on AFP server */ 
#define AS_AFPINFO 14 /* AFP file info, attrib., etc */ 
#define AS_AFPDIRID 15 /* AFP directory ID */ 
/* matrix of entry types and their usage: 
* 
v Macintosh Pro-DOS MS-DOS AFP server 
we a am a a Ee TA 8 er a 
Aes l AS_DATA XXX XXX XXX XXX 
Fa 2 AS_RESOURCE XXX XXX 
e AS_REALNAME XXX XXX XXX XXX 
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* 

* 4 AS COMMENT XXX 

te g AS_ICONBW XXX 

Eg <6 AS_ICONCOLOR XXX 

* 

w8 AS_FILEDATES XXX XXX XXX XXX 
* 9  AS_FINDERINFO xxx 

* 10  AS_MACINFO XxX 

* 

cae bl AS_PRODOSINFO XXX 

Ad, AS_MSDOSINFO XXX 

* 

* 13 AS_AFPNAME XXX 
* 14 AS_AFPINFO XxX 
* 15 AS_AFPDIRID XXX 
*/ 


/* entry ID 1, data fork of file - arbitrary length octet string */ 


/* entry ID 2, resource fork - arbitrary length opaque octet string; 


* as created and managed by Mac O.S. resoure manager 
*/ 

/* entry ID 3, file’s name as created on home file system - arbitrary 
s length octet string; usually short, printable ASCII 
x 

/* entry ID 4, standard Macintosh comment - arbitrary length octet 
* string; printable ASCII, claimed 200 chars or less 
*/ 


/* This is probably a simple duplicate of the 128 octet bitmap 
* stored as the ’ICON’ resource or the icon element from an ’ICN#’ 
* resource. 


47 


struct ASIconBW /* entry ID 5, standard Mac black and white icon */ 
{ 
uint32 bitrow[32]; /* 32 rows of 32 1-bit pixels */ 

}; /* ASIconBW */ 

typedef struct ASIconBW ASIconBW; 

/* entry ID 6, "standard" Macintosh color icon - several competing 
color icons are defined. Given the copyright dates 

of the Inside Macintosh volumes, the ’cicn’ resource predominated 


when the AppleSingle Developer’s Note was written (most probable 
candidate). See Inside Macintosh, Volume V, pages 64 & 80-81 for 


+ F + F 
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* a description of ’cicn’ resources. 

* 

* With System 7, Apple introduced icon families. They consist of: 
* large (32x32) B&W icon, 1-bit/pixel, type ‘'ICN#’, 

x small (16x16) B&W icon, 1-bit/pixel, type ‘’ics#’, 

* large (32x32) color icon, 4-bits/pixel, type '’icl4’, 

* small (16x16) color icon, 4-bits/pixel, type ’ics4’, 

x large (32x32) color icon, 8-bits/pixel, type ’icl8’, and 
X small (16x16) color icon, 8-bits/pixel, type 'ics8’. 

* If entry ID 6 is one of these, take your pick. See Inside 

* Macintosh, Volume VI, pages 2-18 to 2-22 and 9-9 to 9-13, for 
* descriptions. 

ei 


/* entry ID 7, not used */ 


/* Times are stored as a "Signed number of seconds before of after 
12:00 a.m. (midnight), January 1, 2000 Greenwich Mean Time (GMT). 
* Applications must convert to their native date and time 
conventions." Any unknown entries are set to 0x80000000 
(earliest reasonable time). 


*/ 


struct ASFileDates /* entry ID 8, file dates info */ 
{ 
sint32 create; /* file creation date/time */ 
sint32 modify; /* last modification date/time */ 
sint32 backup; /* last backup date/time */ 
sint32 access; /* last access date/time */ 
}; /* ASFileDates */ 


typedef struct ASFileDates ASFileDates; 


/* See older Inside Macintosh, Volume II, page 115 for 
* PBGetFileInfo(), and Volume IV, page 155, for PBGetCatInfo(). 
a): 


/* entry ID 9, Macintosh Finder info & extended info */ 
struct ASFinderInfo 


{ 
Finfo ioFlFndriInfo; /* PBGetFileInfo() or PBGetCatInfo() */ 


FXInfo ioFlXFndrinfo; /* PBGetCatInfo() (HFS only) */ 
}; /* ASFinderInfo */ 
typedef struct ASFinderInfo ASFinderInfo; 


struct ASMacInfo /* entry ID 10, Macintosh file information */ 


{ 
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uchar8 filler[3]; /* filler, currently all bits 0 */ 
uchar8 ioFlAttrib; /* PBGetFileInfo() or PBGetCatInfo() */ 
}; /* ASMacInfo */ 


typedef struct ASMacInfo ASMacInfo; 


#define AS PROTECTED 0x0002 /* protected bit */ 
#define AS LOCKED 0x0001 /* locked bit */ 


/* NOTE: ProDOS-16 and GS/OS use entire fields. ProDOS-8 uses low 
* order half of each item (low byte in access & filetype, low word 


* in auxtype); remainder of each field should be zero filled. 
xy 
struct ASProdosInfo /* entry ID 11, ProDOS file information */ 


{ 
uintl6 access; /* access word */ 
uintl6 filetype; /* file type of original file */ 
uint32 auxtype; /* auxiliary type of the orig file */ 
}; /* ASProDosInfo */ 


typedef struct ASProdosInfo ASProdosInfo; 


/* MS-DOS file attributes occupy 1 octet; since the Developer Note 
* is unspecific, I’ve placed them in the low order portion of the 
* field (based on example of other ASMacInfo & ASProdosInfo). 
$ 


struct ASMsdosInfo /* entry ID 12, MS-DOS file information */ 
{ 
uchar8 filler; /* filler, currently all bits 0 */ 
uchar8 attr; /* _dos_getfileattr(), MS-DOS */ 
/* interrupt 21h function 4300h */ 
}; /* ASMsdosInfo */ 


typedef struct ASMsdosInfo ASMsdosInfo; 


#define AS_DOS_NORMAL 0x00 /* normal file (all bits clear) */ 
#define AS_DOS_READONLY 0x01 /* file is read-only */ 

#define AS DOS HIDDEN 0x02 /* hidden file (not shown by DIR) */ 
#define AS _DOS_SYSTEM 0x04 /* system file (not shown by DIR) */ 
#define AS _DOS_VOLID 0x08 /* volume label (only in root dir) */ 
#define AS_DOS_SUBDIR 0x10 /* file is a subdirectory */ 

#define AS_DOS_ARCHIVE 0x20 /* new or modified (needs backup) */ 


/* entry ID 13, short file name on AFP server - arbitrary length 
* 


octet string; usualy printable ASCII starting with 
X rir (0x21) 
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struct ASAfpInfo 


{ 
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uchar8 filler[3]; /* 
uchar8 attr; /* file 
}; /* ASAfpInfo */ 


typedef 


#define 
#define 
#define 
#define 


struct ASAfpInfo 


AS_AFP_Invisible 
AS_AFP_MultiUser 
AS_AFP_System 


filler, 


/* entry ID 12, AFP server file information */ 


currently all bits 0 */ 
attributes */ 


ASAfpInfo; 


0x01 
0x02 
0x04 


AS_AFP_BackupNeeded 0x40 


struct ASAfpDirId 


{ 


uint32 dirid; 


}; /* ASAfpDirId */ 


/* entry 


/* 
/* 
/* 
/* 


ID 


file is invisible */ 

simultaneous access allowed */ 
system file */ 

new or modified (needs backup) */ 


15, AFP server directory ID */ 


/* file’s directory ID on AFP server */ 


typedef struct ASAfpDirId ASAfpDirId; 


/* 


* The format of an AppleSingle/AppleDouble header 


*/ 


struct AppleSingle /* format of disk file */ 


{ 


ASHeader header; 


/* AppleSingle header part */ 


ASEntry entry[1]; /* array of entry descriptors */ 
/* uchar8 filedata[]; 
}; /* AppleSingle */ 


/* followed by rest of file */ 


typedef struct AppleSingle AppleSingle; 


/* 


* FINAL REMINDER: the Motorola 680x0 is a big-endian architecture! 


e/ 


/* End of applefile.h */ 


Faltstrom, 


Crocker & Fair 


[Page 16] 


